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Today’s  Speaker 


Rob  Wojcik  is  a  member  of  the  technical  staff  in  the  Research, 
Technology,  and  System  Solutions  Program  at  the  SEI,  a 
position  he  has  held  since  2004.  In  his  current  position,  he 
performs  training  and  consulting  in  software  architecture 
technology  and  software  architecture  evaluations.  Prior  to  his 
position  at  the  SEI,  over  twenty  five  years  of  his  career  were 
dedicated  to  developing  software  systems  that  utilize  traditional 
as  well  as  artificial  intelligence  and  object  oriented  technologies. 
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Polling  Question  #1 


How  did  you  hear  about  this  webinar? 

i. Email  invitation  from  the  SEI 
2.SEI  Website 

3.Website  with  webinar  calendar  (i.e.,  www.webinar-directory.com) 
4.Social  Media  (i.e.,  Linkedln,  Twitter) 

5.SEI  Member  Bulletin 
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Software  Engineering  Institute  (SEI) 


Department  of  Defense  R&D  Laboratory  (FFRDC) 


Created  in  1984 


Under  contract  to  Carnegie  Mellon  University 


Offices  in  Pittsburgh,  PA;  Washington,  DC;  and  Frankfurt,  Germany 


SEI  Mission:  advance  software  and  related  disciplines  to  ensure  the 
development  and  operation  of  systems  with  predictable  and  improved  cost, 
schedule,  and  quality. 
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Research,  Technology,  and  System  Solutions 
(RTSS)Program 


Vision 

•  Enable  assured  and  flexible  system  capabilities  at  all  scales. 


Mission 

•  Focus  on  the  structure  and  behavior  of  software-reliant  systems 


Portfolio  of  RTSS  Program  Work 


Initiatives 

•  Architecture-Centric  Engineering 

•  System  of  Systems  Practice 

•  System  of  Systems  Software  Assurance 

•  Product  Line  Practice 
Cross-Cutting  Efforts 

•  Concept  Lab 

•  Integrating  Solutions 

•  Ultra-Large-Scale  Systems 
Independent  Research  and  Development 


infer  Software  Engineering  Institute  Carnegie  Mellon 


D2010  Carnegie  Mellon  University 


Page 


Today’s  Topics 


•  What  is  Software  Architecture? 

•  Why  is  Software  Architecture  Important? 

•  Which  Requirements  Are  Most  Important  To  Architectural  Design? 

•  What  Else  Influences  Software  Architecture? 


I’ll  take  questions  at  the  end  of  the  presentation. 
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How  Much  Do  You  Know? 


a)  I  know  a  whole  lot  about  software  architecture 

b)  I  know  enough  about  software  architecture  to  get  by 

c)  I  know  very  little  about  software  architecture 

d)  What  the  heck  is  software  architecture? 
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Many  Definitions  for  Software  Architecture 


Ramanujam:  an  iterative  framework  between 
software  components  required  to  meet  the  stated 
objectives  of  the  business,  in  terms  of  cost  to 
develop/maintain  the  software  components,  time 
to  market,  and  life  expectancy  of  the  components 


Alfred:  Software  architecture  consists  of  the 
rules  and  principles  for  how  a  system  is 
decomposed  into  its  component  parts,  the 
rationale  for  how  responsibilities  are 
allocated  among  those  parts,  and  the 
policies  and  mechanisms  that  coordinate 
the  interactions  between  those  parts  as 
they  collaborate  to  fulfill  the  purpose  of  the 
system.  Software  architecture  is  at  once 
the  partitioning  of  a  system  into  its 
significant  elements,  and  the  organization 
and  integration  of  those  elements  into  a 
cohesive  whole. 

RUP:  the  set  of  significant  decisions 
about  the  organization  of  a  software 
system,  the  selection  of  the  structural 
elements  and  their  interfaces  by  which 
the  system  is  composed,  together  with 
their  behavior  as  specified  in  the 
collaborations  among  those  elements, 
the  composition  of  these  structural  and 
behavioral  elements  into  progressively 
larger  subsystems,  and  the  architectural 
style  that  guides  this  organization— 
these  elements  and  their  interfaces, 
their  collaborations,  and  their 
composition 


Software  Engineering  Institute: 
the  structure  or  structures  of  the 
system,  which  comprise  the 
software  elements,  the  externally 
visible  properties  of  those  elements, 
and  the  relationships  among  them 


ANSI/IEEE:  the  fundamental 
organization  of  a  system, 
embodied  in  its  components, 
their  relationships  to  each 
other  and  the  environment, 
and  the  principles  governing 
its  design  and  evolution 


Adabala:  a  style  that  is  proven  scientifically  and 
adopted  by  the  engineering  discipline,  with  which  a 
software  is  developed  so  as  to  sustain  and  adopt  to 
the  growing  needs  of  the  industry  from  time  to  time.. 


Riemenschneider:  the  mapping  from  the  problem  space 
to  the  solution  space,  where  the  problem  space  is 
devoid  of  implementation  concerns  and  the  solution 
space  is  the  sum  total  of  all  implementation  concerns 


Mulvaney:  a  set  of  implementation  elements 
together  with  the  mechanisms  through  which  they 
collaborate  to  provide  the  system's  required 
functionality 


Ahmed:  a  coherent  set  of 
abstract  patterns,  or  principles, 
guiding  the  design  of  each  aspect 
of  a  large  software  system... 


Pandey:  the  blueprint  of  the  various 
framework  components  that  coordinate 
together  to  satisfy  the  design  guidelines 
of  a  specific  domain 


-Ipgr  Software  Engineering  Institute 


Matthaeus:  A  configurable  skeleton  of  any  kind  of  software  beast  on 
which  you  hang  implementation  specific  muscle  to  make  it  live 
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Some  Things  Remain  Certain  - 1 


Software  architecture 

•  is  an  abstraction  that  describes  software  elements 

•  addresses  the  roles,  responsibilities,  behaviors  and  properties  of 
software  elements 

•  addresses  the  relationships  between  software  elements 

•  shows  what  software  elements  provide  to  and  require  from  each 
other 

•  shows  the  relationship  to  non-software  elements 

•  is  described  from  many  different  perspectives 
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Some  Things  Remain  Certain  -  2 


Every  software  system  has  an  architecture. 


A  software  architecture  is  not  inherently  good  or  bad. 
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Today’s  Topics 
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Why  Is  Software  Architecture  Important? 


It’s  a  vehicle  for  communication. 

It’s  a  manifestation  of  earliest  design  decisions  that 

•  defines  implementation  constraints 

•  relates  to  organizational  structure 

•  provides  the  basis  for  project  artifacts  and  activities 

•  permits/precludes  achieving  requirements 

•  allows  us  to  predict  system  qualities 

•  allows  us  to  control  complexity 

•  allows  us  to  reason  about  and  manage  change 

•  allows  us  to  develop  a  skeletal  system 

•  provides  a  sound  basis  for  cost  and  schedule  estimates 
It’s  a  transferable,  reusable  abstraction. 
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Which  Requirements  Are  Most  Important  to 
Architectural  Design? 


Functional 

requirements 

Design 

constraints 

Quality  attribute 
requirements 


Software 

Architecture 


What  determines  whether  these  requirements  are  met? 

Which  requirements  are  the  most  important  when  it  comes  to 
structuring  an  architecture? 
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Something  to  Consider 


What’s  wrong  with  designing  a  system  that  has  one  big  source  module,  one 
big  object  module,  and  one  big  executable  as  long  as  it  functions  properly? 


buildability 

modifiability 

testability 

complexity 

maintainability 


Module 


1,999,999 

2,000,000 


portability 

reliability 

distributability 

availability 

reusability 


Others? 

Which  requirements  do  you  think  would  be 
negatively  impacted  by  this  “design”? 
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Here’s  the  Point! 


If  functionality  is  the  only  thing  that  matters,  any  software  architecture 
will  do! 


It’s  the  requirements  that  are  above  and  beyond  functionality  that 
require  us  to  structure  an  architecture.  They  include: 

•  design  constraints 

•  quality  attributes 
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Requirements  Elicitation 


architectural  design! 

Eliciting 

functional  requirements 


and  design  constraints 


Eliciting 
quality  attribute 
requirements 


Good  Job 


Bad  Job 
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Difficulties  in  Eliciting  Quality  Attribute 
Requirements 


Non-Operational  requirements 

•  “The  system  must  be  easy  to  use.” 

•  “The  system  must  have  high  performance.” 

•  “The  system  must  be  portable.” 

Debating  the  quality  attribute  to  which  a  system  behavior  belongs 

•  “The  system  must  process  10,000  messages  per  second.” 

Vocabulary  variations 

•  Everyone  knows  what  “high  performance”  means,  right? 
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Other  Influences  on  the  Architecture 


Requirements 


Technical 

Business 

Social 


Software 

Architecture 


Software  architecture  is  influenced  by  the  technical,  business,  and 
social  environment. 
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Examples  of  Other  Influences 


Stakeholders 

•  customers,  users,  managers,  marketing,  developers,  maintainers,  etc. 
Development  organization 

•  immediate  and  long  term  business  goals 

•  organizational  structure 
Technical  environment 

•  object  oriented,  WWW,  intelligent  agents,  EJB,  service  oriented,  J2EE, 
thin  client,  .NET,  etc. 

Background  and  experience 

•  architect  and  organizational  experience 

•  education  and  training 
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What  Architecture  Influences 


Requirements 


Technical 

Business 

Social 


An  architecture  can  influence  the  technical,  business,  and  social 
environment. 
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Examples  of  What  Architecture  Can  Influence 


Development  organization 

•  structure,  goals,  artifacts,  etc. 

Stakeholder  requirements 

•  demand  for  similar  features,  existing  components  and  system 
Technical  environment 

•  relational  databases,  WWW,  service  oriented  architectures,  etc. 
Background  and  experience 

•  promote  approaches  that  have  been  successful 

•  reject  approaches  that  have  failed 
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Understanding  These  Influences 


Requirements 


Technical 

Business 

Social 


Understanding  this  cycle  of  influences  helps  us  to  plan  for  and  manage 
change  throughout  the  lifetime  of  a  system. 
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Conclusion 


Software  architecture  is  important! 


Every  software  system  has  an  architecture! 


Quality  attribute  requirements  are  critical! 


Requirements  aren’t  the  only  things  that  influence  software  architectures! 
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For  More  Information 


Software  Architecture  in  Practice,  2nd  edition 

written  by  Len  Bass,  Paul  Clements,  &  Rick  Kazman 
and  published  by  Addison-Wesley  as  part  of  the 
SEI  Series  in  Software  Engineering 


Other  information  is  provided  at 
http  ://www.  se  i .  cm  u .  ed  u/arch  itect  u  re/. 

Contact  Rob  Wojcik 

Software  Engineering  Institute 
rwojcik@sei.cmu.edu 


Software 
Architecture 
in  Practice 

Scvxiik)  Kiiitiun 


r*il  OnaMh 
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Proof  of  your  skill 

from  a  world  leader  in 
software  engineering. 

Become  an  SEI-Certified 
ATAM  Leader. 


^  www.sei.cmu.edu/certification/architecture/atam 
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Want  a  Closer  Connection  t 

A 1  /  M/  Wm\Z. 


Become  an  SEI  Member! 

^  www.sei.cmu.edu/membership 
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For  more  than  20  years,  the  SEI  has  been 
at  the  forefront  of  software  engineering. 


By  becoming  an  SEI  Partner,  you  join  forces  with  a  software 
engineering  pioneer  and  an  institute  whose  credibility  provides 
a  solid  foundation  during  uncertain  economic  times. 


SEI  Partner  Network 

^  www.sei.cmu.edu/partners 


Software  Engineering  Institute  ^ - •  ™  n 


Carnegie  Mellon 


©2010  Carnegie  Mellon  University 


Page  32 


SEI  Training 

^  www.sei.cmu.edu/training 
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•NO  WARRANTY 


•THIS  MATERIAL  OF  CARNEGIE  MELLON  UNIVERSITY  AND  ITS  SOFTWARE  ENGINEERING 
INSTITUTE  IS  FURNISHED  ON  AN  “AS-IS"  BASIS.  CARNEGIE  MELLON  UNIVERSITY  MAKES 
NO  WARRANTIES  OF  ANY  KIND,  EITHER  EXPRESSED  OR  IMPLIED,  AS  TO  ANY  MATTER 
INCLUDING,  BUT  NOT  LIMITED  TO,  WARRANTY  OF  FITNESS  FORTORPOSE  OR 

MERCHANTABILITY,  EXCLUSIVITY,  OR  RESULTS  OBTAINED  FROM  USE  OF  THE 
MATERIAL.  CARNEGIE  MELLON  UNIVERSITY  DOES  NOT  MAKE  ANY  WARRANTY  OF  ANY 
KIND  WITH  RESPECT  TO  FREEDOM  FROM  PATENT,  TRADEMARK,  OR  COPYRIGHT 
INFRINGEMENT. 

•Use  of  any  trademarks  in  this  presentation  is  not  intended  in  any  way  to  infringe  on  the  rights  of 
the  trademark  holder. 

•This  Presentation  may  be  reproduced  in  its  entirety,  without  modification,  and  freely  distributed  in 
written  or  electronic  form  without  requesting  formal  permission.  Permission  is  required  for  any 
other  use.  Requests  for  permission  should  be  directed  to  the  Software  Engineering  Institute  at 
permission@sei.cmu.edu. 

•This  work  was  created  in  the  performance  of  Federal  Government  Contract  Number  FA8721-05- 
C-0003  with  Carnegie  Mellon  University  for  the  operation  of  the  Software  Engineering  Institute,  a 
federally  funded  research  and  development  center.  The  Government  of  the  United  States  has  a 
royalty-free  government-purpose  license  to  use,  duplicate,  or  disclose  the  work,  in  whole  or  in  part 
and  in  any  manner,  and  to  have  or  permit  others  to  do  so,  for  government  purposes  pursuant  to 
the  copyright  license  under  the  clause  at  252.227-7013. 
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